For data-driven companies, data insights are only as valuable as the platform that delivers them. As organizations modernize their technology stack, choosing the right reporting solution- whether SSRS, Power BI, or Paginated Reports – becomes a critical decision. With multiple options available, establishing clear evaluation criteria is essential to avoid costly missteps and future migration challenges. Are you struggling to decide which reporting tool fits your specific needs? If you’re evaluating SSRS, Power BI, or Paginated Reports for your organization, this article is for you. I’m confident this framework will help you make the right reporting tool decision and avoid common pitfalls that waste time and money. Understanding the Three Options Before we dive into the decision framework, let’s clarify what each tool actually is: SSRS (SQL Server Reporting Services) – The traditional Microsoft reporting platform that’s been around since 2004. It’s pixel-perfect, print-oriented, and runs on-premises. Power BI – Microsoft’s modern cloud-based analytics platform focused on interactive dashboards, data exploration, and self-service analytics. Paginated Reports in Power BI – The evolution of SSRS technology integrated into Power BI Service, combining traditional reporting with modern cloud capabilities. Step 1: Identify Your Primary Use Case Ask yourself this fundamental question: What is the report’s main purpose? Use Case A: Interactive Exploration and Analysis Best Choice: Power BI Choose Power BI when: Example Scenarios: Sales performance dashboards, Executive KPI monitoring, Marketing analytics platforms, Operational metrics tracking Use Case B: Precise Formatted Documents Best Choice: Paginated and SSRS Reports Choose Paginated Reports when: Example Scenarios: The Feature Comparison Matrix Power BI Standard Reports Strengths: Limitations: Paginated and SSRS Reports Strengths: Limitations: Cost Analysis: Making the Business Case Power BI & Power BI Paginated Reports Licensing Power BI Pro: $14/user/month SSRS Costs Important Note: If you’re already using Microsoft Dynamics 365 or Dynamics CRM, SSRS functionality is included at no additional cost. When SSRS is Already Available: Infrastructure Costs (If Not Using Dynamics): To conclude, I encourage you to take a systematic approach to your reporting tool decision. Identify your top 5 most important reports and categorize them by use case. This systematic approach will reveal the right decision for your organization and help you build a business case for stakeholders. Need help evaluating your specific reporting scenario? Connect with us at transform@cloudfronts.com for personalized guidance on choosing and implementing the right reporting solution. Making the right decision today will save you years of headaches and wasted resources.

Are you struggling to build secure, low-latency APIs on Azure without spinning up expensive always-on infrastructure? Traditional serverless models like the Azure Functions Consumption Plan are great for scaling, but they fall short when it comes to VNET integration and consistent low latency. Enterprises often need to connect serverless APIs to internal databases or secure networks — and until recently, that meant upgrading to Premium Plans or sacrificing the cost benefits of serverless. That’s where the Azure Functions Flex Consumption Plan changes the game. It brings together the elasticity of serverless, the security of VNETs, and latency performance that matches dedicated infrastructure — all while keeping your costs optimized. What is Azure Functions Flex Consumption? Azure Functions Flex Consumption is the newest hosting plan designed to power enterprise-grade serverless applications. It offers more control and flexibility without giving up the pay-per-use efficiency of the traditional Consumption Plan. Key capabilities include: Why This Matters APIs are the backbone of every digital product. In industries like finance, retail, and healthcare, response times and data security are mission critical. Flex Consumption ensures your serverless APIs are always ready, fast, and safely contained within your private network — ideal for internal or hybrid architectures. VNET Integration: Security Without Complexity Security has always been the biggest limitation of traditional serverless plans. With Flex Consumption, Azure Functions can now run inside your Virtual Network (VNET). This allows your Functions to: In short: You can now build fully private, VNET-secure APIs without maintaining dedicated infrastructure. Building a VNET-Secure Serverless API: Step-by-Step Step 1: Create a Function App in Flex Consumption Plan Step 2: Configure VNET Integration Step 3: Deploy Your API CodeUse Azure DevOps, GitHub Actions, or VS Code to deploy your function app just like any other Azure Function. Step 4: Secure Your API How It Compares to Other Hosting Plans Feature Consumption Premium Flex Consumption Auto Scale to Zero ✅ ❌ ✅ VNET Integration ❌ ✅ ✅ Cold Start Optimized ⚠️ ✅ ✅ Cost Efficiency ⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐⭐ Enterprise Security ❌ ✅ ✅ Flex Consumption truly combines the best of both worlds – the agility of serverless and the power of enterprise networking. Real-World Use Case Example A large retail enterprise needed to modernize its internal inventory API system.They were running on Premium Functions Plan for VNET access but were overpaying due to idle resource costs. After migrating to Flex Consumption, they achieved: This allowed them to maintain compliance, improve responsiveness, and simplify their architecture — all with minimal migration effort. To conclude, in today’s API-driven world, you shouldn’t have to choose between speed, cost, and security. With Azure Functions Flex Consumption, you can finally deploy VNET-secure, low-latency serverless APIs that scale seamlessly and stay protected inside your private network. Next Step:Start by migrating one of your internal APIs to the Flex Consumption Plan. Test the latency, monitor costs, and see the difference in performance. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudFronts.com

Sometimes, it becomes necessary to correct a posted transaction. Instead of manually adjusting or attempting to delete it, you can utilize the reverse functionality. Reverse journal postings are helpful for correcting mistakes or removing outdated accrual entries before creating new ones. A reversal mirrors the original entry but uses the opposite sign in the Amount field. It must use the same document number and posting date as the original. After reversing, the correct entry must be posted. Only entries created from general journal lines can be reversed, and each entry can be reversed only once. To undo a receipt or shipment that hasn’t been invoiced, use the Undo action on the posted document. This applies to Item and Resource quantities. You can undo postings if an incorrect negative quantity was entered (for example, a purchase receipt with the wrong item quantity and not yet invoiced). Similarly, incorrect positive quantities posted as shipped but not invoiced, such as sales shipments or purchase return shipments. can also be undone. Pre-requisites Business Central onCloud Steps: Open the transaction you wish to reverse. In this case, we aim to reverse the payment for the customer shown below. Click on Ledger Entries to view all transactions associated with this customer. As shown, this payment has already been applied to an invoice. Therefore, you must first unapply the payment before proceeding. Use the Unapply Entries action button to unapply the entries for the selected customer. Once you successfully unapplied payment you can see “remaiing amount” is equal to “Amount” field. Now click on “Reverse Transaction”. You can view the related entries for this transaction. Click the Reverse button, and a pop-up will appear once the reversal entries have been posted for the selected transaction. The reverse entry has now been created, reflecting the same document number and amount. Leveraging the reverse transaction functionality in Business Central enables businesses to correct errors seamlessly, improve operational efficiency, and uphold the integrity of their financial data. Whether managing invoices, payments, or other ledger entries, this feature is an essential tool for maintaining transparency and accuracy in your financial workflows. To Conclude, the reverse transaction feature in Business Central is a powerful tool that simplifies the process of correcting posted transactions. Instead of manually adjusting or deleting entries, you can efficiently reverse them, ensuring your financial records remain accurate and consistent. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Tax Deducted at Source (TDS) with concessional rates on threshold limits is a provision that enables eligible taxpayers to benefit from lower TDS rates, as permitted by government-issued certificates. These certificates are granted to individuals or entities that meet specific criteria, such as lower tax liability or involvement in designated transactions. By implementing concessional rates, taxpayers can effectively manage their immediate tax burden, enhance cash flow, and ensure compliance with regulatory requirements. This guide outlines the step-by-step process for configuring concessional TDS rates in Microsoft Dynamics 365 Finance & Operations (D365 F&O) to facilitate accurate tax calculations and ensure seamless compliance. Step-by-Step Configuration of TDS in D365 F&O 1. Setting Up the Withholding Tax Code Navigate to Tax → Indirect Taxes → Withholding Tax → Withholding Tax Code and either select an existing tax code or create a new one. Ensure all required details are entered accurately. 2. Defining Concessional TDS Rates Click on Values and insert the applicable TDS rates as per government guidelines. 3. Configuring Threshold Limits Access Tax → Indirect Taxes → Withholding Tax → Withholding Tax Code and select Threshold Designer. Enter the threshold limits for TDS rates, specifying the applicable conditions when these limits are reached. 4. Establishing Post-Threshold Tax Treatment Provide details regarding the applicable tax rate once the threshold limit is exceeded to ensure proper compliance. 5. Assigning Threshold References Navigate to Tax → Indirect Taxes → Withholding Tax → Withholding Tax Code and select Threshold Reference. Assign the relevant Vendor, specific group, and threshold code to ensure accurate tax calculations. 6. Creating a TDS Group Define a new TDS Group and link it with the recently created withholding tax code to streamline tax application across transactions. 7. Configuring the Tax Code in Designer Use the Designer tool to reassign the withholding tax code, ensuring correct integration within tax processing workflows. 8. Associating the Tax Group with Vendors Assign the defined Tax Group to the relevant vendor. Once this is set up, proceed with Vendor Invoice postings or Purchase Order creation, ensuring that the concessional TDS rates are accurately applied to financial transactions. Proper configuration of TDS with concessional rates in D365 F&O ensures compliance with tax regulations while optimizing cash flow for eligible taxpayers. By implementing the correct withholding tax setup, organizations can streamline their tax processes and minimize unnecessary deductions. This structured approach enhances financial accuracy and simplifies tax management, contributing to more efficient business operations. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Building low-latency, VNET-secure APIs with Azure Functions Flex Consumption is only the beginning.The next step toward modernization is setting up a DevOps release pipeline that automatically deploys your Function Apps-even across multiple regions – using Azure CLI. In this blog, we’ll explore how to implement a CI/CD pipeline using Azure DevOps and Azure CLI to deploy Azure Functions (Flex Consumption), handle cross-platform deployment scenarios, and ensure global availability. Step-by-Step Guide: Azure DevOps Pipeline for Azure Functions Flex Consumption Step 1: Prerequisites You’ll need: Step 2: Provision Function Infrastructure Using Azure CLI Step 3: Configure Azure DevOps Release Pipeline Important Note: Windows vs Linux in Flex Consumption While creating your pipeline, you might notice a critical difference: The Azure Functions Flex Consumption plan only supports Linux environments. If your existing Azure Function was originally created on a Windows-based plan, you cannot use the standard “Azure Function App Deploy” DevOps task, as it assumes Windows compatibility and won’t deploy successfully to Linux-based Flex Consumption. To overcome this, you must use Azure CLI commands (config-zip deployment) — exactly as shown above — to manually upload and deploy your packaged function code. This method works regardless of the OS runtime and ensures smooth deployment to Flex Consumption Functions without compatibility issues. Tip: Before migration, confirm that your Function’s runtime stack supports Linux. Most modern stacks like .NET 6+, Node.js, and Python run natively on Linux in Flex Consumption. Step 4: Secure Configurations and Secrets Use Azure Key Vault integration to safely inject configuration values: Step 5: Enable VNET Integration If your Function App accesses internal resources, enable VNET integration: Step 6: Multi-Region Deployment for High Availability For global coverage, you can deploy your Function Apps to multiple regions using Azure CLI: Dynamic Version (Recommended): This ensures consistent global rollouts across regions. Step 7: Rollback Strategy If deployment fails in a specific region, your pipeline can automatically roll back: Best Practices a. Use YAML pipelines for version-controlled CI/CDb. Use Azure CLI for Flex Consumption deployments (Linux runtime only)c. Add manual approvals for productiond. Monitor rollouts via Azure Monitore. Keep deployment scripts modular and parameterized To conclude, automating deployments for Azure Functions Flex Consumption using Azure DevOps and Azure CLI gives you: If your current Azure Function runs on Windows, remember — Flex Consumption supports only Linux-based plans, so CLI-based deployments are the way forward. Next Step:Start with one Function App pipeline, validate it in a Linux Flex environment, and expand globally. For expert support in automating Azure serverless solutions, connect with CloudFronts — your trusted Azure integration partner. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

When working on report customizations in Microsoft Dynamics 365 Business Central, one common challenge is maintaining a consistent layout regardless of how many lines are present in the data source. This situation often arises in reports like Purchase Orders, Sales Orders, or Invoices, where the line section expands or contracts based on the number of lines in the dataset. However, certain business scenarios demand a fixed or uniform presentation, such as when a client wants consistent spacing or placeholders for manual inputs. This article demonstrates how you can achieve this flexibility purely through RDLC layout design – without making any changes in AL or dataset logic. Business Requirement The objective was to design a Purchase Order report where the line area maintains a consistent structure, independent of how many lines exist in the actual data. In other words, the report layout should not necessarily reflect the dataset exactly as it is. The idea was to ensure visual uniformity while keeping the underlying data logic simple. Proposed Solution The solution was implemented directly in the RDLC report layout by creating two tables and controlling their visibility through expressions. There was no need to align them in the same position one table was placed above the other. RDLC automatically handled which one to display at runtime based on the visibility conditions. Table 1 – Actual Purchase Lines Displays the real data from the Purchase Line dataset. Table 2 – Structured or Blank Layout Displays a predefined structure (for example, blank rows) when fewer lines are available. This design ensures that whichever table meets the visibility condition is rendered, maintaining layout flow automatically. Implementation Steps 1. Add Two Tables in the RDLC Layout 2. Set Visibility Conditions To control which table appears at runtime, open each table’s properties and go to:Table Properties → Visibility → Hidden → Expression Then apply the following expressions: For Table 1 (Actual Purchase Lines) =IIF(CountRows(“DataSet_Result”) <= 8, True, False) Hides the actual data table when the dataset has fewer rows. For Table 2 (Structured or Blank Layout) =IIF(CountRows(“DataSet_Result”) > 8, True, False) Hides the structured or blank table when enough data rows are available. Note: The number “8” is just an example threshold. You can set any value that fits your design requirement. Result At runtime: The RDLC engine handles layout adjustment, ensuring the report always looks uniform and visually balanced – without any need for AL code changes or temporary data handling. Advantages of This Approach Benefit Description No AL Code Changes Achieved entirely within RDLC layout. Upgrade Friendly Dataset and report objects remain unchanged. Automatic Layout Flow RDLC adjusts which table is displayed automatically. Professional Appearance Ensures consistent formatting and structure across all reports. Key Takeaways This simple yet effective approach shows that report design in Business Central can be made flexible without altering data logic.By using two tables with visibility expressions, you can create reports that adapt their appearance automatically – keeping the layout professional, stable, and easy to maintain. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

Enterprises today are collecting more data than ever before, yet most leaders admit they don’t fully trust the insights derived from it. Inconsistent formats, missing values, and unreliable sources create what’s often called a data swamp an environment where data exists but can’t be used confidently for decision-making.  Clean, trusted data isn’t just a technical concern; it’s a business imperative. Without it, analytics, AI, and forecasting lose credibility and transformation initiatives stall before they start.  That’s where the Medallion Architecture comes in. It provides a structured, layered framework for transforming raw, unreliable data into consistent, analytics-ready insights that executives can trust.  At CloudFront’s, a Microsoft and Databricks partner, we’ve implemented this architecture to help enterprises modernize their data estates and unlock the full potential of their analytics investments.  Why Data Trust Matters More Than Ever  CIOs and data leaders today face a paradox: while data volumes are skyrocketing, confidence in that data is shrinking.  Poor data quality leads to:  In short, when data can’t be trusted, every downstream process from reporting to machine learning is compromised. The Medallion Architecture directly addresses this challenge by enforcing data quality, lineage, and governance at every stage.  What Is the Medallion Architecture?  The Medallion Architecture is a modern, layered data design framework introduced by Databricks. It organizes data into three progressive layers Bronze, Silver, and Gold each refining data quality and usability.  This approach ensures that every layer of data builds upon the last, improving accuracy, consistency, and performance at scale.  Inside Each Layer    Bronze Layer —> Raw and Untouched   The Bronze Layer serves as the raw landing zone for all incoming data. It captures data exactly as it arrives from multiple sources, preserving lineage and ensuring that no information is lost. This layer acts as a foundational source for subsequent transformations.   Silver Layer —> Cleansing and Transformation   At the Silver Layer, the raw data undergoes cleansing and standardization. Duplicates are removed, inconsistent formats are corrected, and business rules are applied. The result is a curated dataset that is consistent, reliable, and analytics ready.   Gold Layer —> Insights and Business Intelligence   The Gold Layer aggregates and enriches data around key business metrics. It powers dashboards, reporting, and advanced analytics, providing decision-makers with accurate and actionable insights.   Example: Data Transformation Across Layers   Layer   Data Example   Processing Applied   Outcome   Bronze   Customer ID: 123, Name: Null, Date: 12-03-24 / 2024-03-12   Raw data captured as-is   Unclean, inconsistent   Silver   Customer ID: 123, Name: Alex, Date: 2024-03-12   Standardization & de-duplication   Clean & consistent   Gold   Customer ID: 123, Name: Alex, Year: 2024   Aggregation for KPIs   Business-ready dataset   This layered approach ensures data becomes progressively more accurate, complete, and valuable.   Building Reliable, Performant Data Pipelines  By leveraging Delta Lake on Databricks, the Medallion Architecture enables enterprises to unify streaming and batch data, automate validations, and ensure schema consistency creating an end-to-end, auditable data pipeline.  This layered approach turns chaotic data flows into a structured, governed, and performant data ecosystem that scales as business needs evolve.  Client Example: Retail Transformation in Action  A leading hardware retailer in the Maldives faced challenges managing inventory and forecasting demand across multiple locations. They needed a unified data model that could deliver real-time visibility and predictive insights.  CloudFront’s implemented the Medallion Architecture using Databricks:  Results:  Key Benefits for Enterprise Leaders  Final Thoughts  Clean, trusted data isn’t a luxury, it’s the foundation of every successful analytics and AI strategy.  The Medallion Architecture gives enterprises a proven, scalable framework to transform disorganized, unreliable data into valuable, business-ready insights.  At CloudFront’s, we help organizations modernize their data foundations with Databricks and Azure delivering the clarity, consistency, and confidence needed for data-driven growth.  Ready to move from data chaos to clarity? Explore our Databricks Services or Talk to a Cloud Architect to start building your trusted analytics foundation today.  We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

In modern business settings, employees spend a significant portion of their time searching for information rather than using it. According to Microsoft, office workers can spend up to 20 % of their working time simply looking for data. With the “Search in company data” feature in Business Central, organizations can now provide users with faster, broader, and more relevant search capabilities—giving them more time to focus on strategic tasks rather than just data retrieval. Using this feature is straightforward and intuitive. You can either highlight any text within Business Central and open the Tell Me window, or type one or more keywords directly into it. Then, select the Search company data option to explore matching information across your system. So instead of opening Item list page and searching item name you can simply use above option. Once you click on Search Company Data it will open Search result with new page. You can simply click on result to open searched item page. You can enable more table to search across them by clicking “Setup where to search” option. To conclude, the Search in Company Data feature in Microsoft Dynamics 365 Business Central empowers users to find information faster and more efficiently. Instead of navigating through multiple pages or lists, users can now access the data they need directly through the Tell Me window. With the added flexibility to configure which tables and fields are searchable, organizations can tailor the experience to meet their specific needs. By simplifying the search process and enabling broader data accessibility, this feature not only saves time but also enhances productivity-allowing users to focus on decision-making and value-driven tasks rather than manual data lookups. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

We’ve all been there. You’re closing out the month, and you spot it: a General Journal line where the “Department” dimension is set to “Sales” but should have been “Marketing.” Or perhaps a purchase invoice was posted with an incorrect “Project” code. In the world of accounting and Microsoft Dynamics 365 Business Central, dimensions are the lifeblood of meaningful reporting, and even a single mistake can ripple through your financial statements, leading to misguided decisions and frantic period-end corrections. Fortunately, Microsoft Dynamics 365 Business Central offers a powerful, built-in safety net: the Dimension Correction feature. This isn’t just a handy tool, it’s a game-changer for financial integrity and auditor peace of mind. What Are Dimensions, and Why Do Mistakes Happen? Before diving into corrections, let’s quickly recap. Dimensions in Business Central are tags like Department, Project, Cost Center, or Region. Instead of creating separate G/L accounts for every possible combination, dimensions allow you to slice and dice your financial data, delivering incredible analytical power. Common Reasons These Errors Occur: In the past, fixing mistakes meant reversing entries, posting manual journals, and leaving a messy audit trail. Not anymore. Enter the Hero: The Dimension Correction Feature The Dimension Correction feature allows you to change dimensions on already posted entries without creating new transactions or affecting original amounts. It simply updates the dimensional context of the existing entry. Key Benefits of Dimension Correction How to Perform a Dimension Correction: A Step-by-Step Guide Let’s walk through correcting a simple example. Scenario: A telephone expense was incorrectly posted to the SALES department. It should have been posted to the MARKETING department. Step 1: Locate the Posted Entry Step 2: Initiate the Dimension Correction Step 3: Make the Correction Step 4: Verify the Change To conclude, The Dimension Correction feature transforms a once-tedious, error-prone process into a controlled, efficient, and auditable task. It empowers your finance team to maintain the integrity of your financial data without complex accounting workarounds. By understanding how to use this feature and following simple best practices, you ensure that your dimensions-and therefore your management reports – are always accurate, reliable, and ready to guide your business forward. We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com

If you’ve worked with data in Business Central, you’ve undoubtedly used the DELETE or DELETEALL commands. They get the job done, but when you’re dealing with massive datasets ike clearing out old ledger entries, archived sales orders, or temporary import tables they can feel painfully slow. There’s a better, faster way. Let’s talk about the TRUNCATE TABLE command, the unsung hero of high-performance data purging. What is TRUNCATE TABLE? In simple terms, TRUNCATE TABLE is a SQL command that instantly removes all rows from a table. Unlike DELETE, it doesn’t log individual row deletions in the transaction log. It’s a bulk operation that de-allocates the data pages used by the table, which is why it’s so incredibly fast. In the context of Business Central, you can execute this command directly from an AL codeunit. Yes, it’s that simple. Calling the .TruncateTable() method on a record variable targets its corresponding table and empties it completely. TRUNCATE TABLE vs. DELETE/DELETEALL: What’s the Difference? This is the crucial part. Choosing the right tool is key to performance and data integrity. Feature TRUNCATE TABLE DELETE / DELETEALL Performance Extremely Fast. Operates at the data page level. Slow. Logs every single row deletion individually. Transaction Log Minimal logging. Fills the log with a single “deallocated page” entry. Heavy logging. Fills the log with an entry for every row deleted. Where Clause No. It’s all or nothing. You cannot add a filter. Yes. You can use SETFILTER or SETRANGE to delete specific records. Table Triggers Does not fire. No OnBeforeDelete or OnAfterDelete triggers are executed. Fires for each row that is deleted. Referential Integrity Can fail if a FOREIGN KEY constraint exists. Respects and checks constraints, potentially failing on related records. Resets Identity Seed Yes. The next record inserted will have the first ID in the series (e.g., 1). No. The identity seed continues from where it left off. Transaction Rollback Can be rolled back if used inside a transaction, but it’s still minimally logged. Can be rolled back, as all individual deletions are logged. When Should You Use TRUNCATE TABLE? Given its power and limitations, TRUNCATE TABLE is perfect for specific scenarios: A Real-World Business Central Example Imagine you have a custom “Data Import Staging” table. Every night, a job imports thousands of items from an external system. The first step is always to clear the staging area. The Slow Way (using DELETEALL): The Blazing-Fast Way (using TRUNCATE TABLE): The performance difference can be staggering, turning a minutes-long operation into one that completes in under a second. Critical Warnings and Best Practices With great power comes great responsibility. The limitations of TRUNCATE TABLE are not just footnotes—they are critical considerations. NO FILTERS! This is the biggest “gotcha.” You cannot use SETRANGE before calling TruncateTable(). The method will ignore any filters and always delete everything. Double and triple-check your code to ensure you are targeting the correct table. Bypasses Business Logic: Because table triggers do not fire, any essential business logic in the OnDelete trigger will be skipped. Do not use TRUNCATE TABLE on tables where the delete triggers perform critical actions (e.g., posting, ledger entry creation, validation). Using it on main transaction tables like “G/L Entry” or “Sales Line” is almost always a bad idea. Foreign Key Constraints: If another table has a foreign key constraint pointing to the table you’re trying to truncate, the command will fail with an error. DELETEALL would also fail in this case, but the error message might be different. To Conclude, TRUNCATE TABLE is a powerful tool that should be in every Business Central developer’s arsenal. When used correctly, it can dramatically improve the performance of data maintenance tasks. The Rule of Thumb: Use DELETEALL when you need to respect business logic, delete specific records, or work with tables that have complex relationships. Use TRUNCATE TABLE when you need to quickly and completely empty a large, standalone table where bypassing business logic is safe and acceptable. Embrace TRUNCATE TABLE for the right jobs and watch your large-scale data operations fly. Reference: https://yzhums.com/67343/, We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfronts.com